Conversation
!cc.stdvec<!quake.measure> --> !quake.measurements<N> Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
* Canonical pattern to fuse size Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
(TODO: Similar changes for Python) Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
the new type instead of vector of quake.measure Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
* Add tests Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
!cc.stdvec<!quake.measure> --> !quake.measurements<N> Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
schweitzpgi
left a comment
schweitzpgi
left a comment
There was a problem hiding this comment.
This looks great, Pradnya.
I'm really not sure if the QIR spec wants us to stick Result* in an Array* bucket or not. My hunch is that it does since using LLVM's alloca instruction will cause QIR verification failures.
by default) Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
`MeasurementsType` in QIR conversion pass. Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
- add our own QIR extension for collection of results - use proper type - simple test Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
This reverts commit 86c0a4a. Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
| return IntegerType::get(ty.getContext(), 64); | ||
| }); | ||
| addConversion([](quake::MeasurementsType ty) { | ||
| return cudaq::cc::PointerType::get(IntegerType::get(ty.getContext(), 8)); |
There was a problem hiding this comment.
Since this is a collection of measurements, chose a pointer like we would have for say, Array*.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Signed-off-by: Pradnya Khalate <148914294+khalatepradnya@users.noreply.github.com>
| target.addDynamicallyLegalOp<quake::DiscriminateOp>( | ||
| [](quake::DiscriminateOp d) { | ||
| return !isa<quake::MeasurementsType>(d.getMeasurement().getType()); | ||
| }); |
There was a problem hiding this comment.
I'm thinking this algorithm may need to be altered a bit to avoid some of the pair-wise checking code.
- Traverse and change all
quake.discriminate %2 : (!quake.measurements<c>) -> !stdvec<i?>to
%2 = quake.get_measure %1[0] : (!quake.measurements<c>) -> !quake.measure
quake.discriminate %2 : (!quake.measure) -> i?
...- Traverse and change all
%m = quake.m[xyz] %1 : (!!quake.veq<c>) -> quake.measurements<c>to
%2 = quake.extract_ref %1[0] : (!quake.veq<c>) -> !quake.ref
%3 = quake.m[xyz] %2 : (!quake.ref) -> !quake.measureand substitute %3 for any users of %m of the form
quake.get_measure %m[0] : (!quake.measurements<c>) -> !quake.measureThere was a problem hiding this comment.
At present, the only way to deal with measurements of unknown length is to have them feed into a discriminate user op.
%1 = quake.mz %0 : (!quake.veq<?>) -> !quake.measurements<?>
%2 = quake.discriminate %1 : (!quake.measurements<?>) -> !cc.stdvec<i4>becomes a loop over both operations, which is what this code did in all cases previously, because it was never the case that we might lower a measurement and a discriminate seperately.
There was a problem hiding this comment.
becomes a loop over both operations, which is what this code did in all cases previously, because it was never the case that we might lower a measurement and a discriminate seperately.
- It is still the case, we are doing eager discriminate as of this PR, the deferred discriminate will happen with PR [C++] Type distinction for measurement result #3800 .
- Q1: Does it still make sense to implement now? I was considering including it in that PR...
- Q2: Regarding the order, should the patterns (specifically
ExpandDiscriminatePattern) be split into 2 phases, i.e. have two calls toapplyPartialConversion, is that what's intended?
* Build fix * Use `isConstantQuantumRefType` instead of checking `hasSpecifiedSize` Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
type Signed-off-by: Pradnya Khalate <pkhalate@nvidia.com>
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
2 participants
!cc.stdvec<!quake.measure>types with!quake.measurements<N>